\chapter{Ferramentas de monitoramento}

\section{Visão operacional}

Considerando falhas operacionais, isto é, falhas que tornam o sistema inoperante, podemos usar algumas ferramentas de monitoramentos em nível de hardware e protocolos de comunicação.

\subsection{Ferramentas de monitoramento potenciais}

Visando tornar a análise e tratamento de falhas mais fácil, exitem diversas ferramentas e sistemas, tanto no mercado, quanto desenvolvidos pela comunidade como o \textit{Zenoss} e o \textit{Zabbix}, é possível analisar vários componentes de um sistema distribuído em diversos módulos.

Segue uma breve descrição e características das ferramentas \textit{Zabbix} e \textit{Zenoss core}:

\subsubsection{Zabbix}

Monitorar os componentes e suas comunicações, podendo gerar relatórios visuais, gerar logs e alertar possíveis falhas.
Pode ser aplicado em diversos níveis da aplicação, como por exemplo; banco de dados MySQL, Web Services e Hardware.

\begin{itemize}
 \item Solução Software Livre GPLV2;
 \item Auto-descoberta de servidores e serviços de rede;
 \item Monitoração distribuída com a administração centralizada via WEB;
 \item Aplicação-servidor compatível com Linux, Solaris, HP-UX, AIX, BSD Livre, Open BSD, Mac OS X;
 \item Aplicação cliente de alto desempenho compatível com Linux, Solaris, HP-UX, AIX, BSD Livre, Open BSD, OS X, Tru64/OSF1, NT4.0, Windows 2000, Windows 2003, Windows XP, Windows Vista;
 \item Monitoramento sem agente;
 \item Autenticação segura de usuário;
 \item Permissões flexíveis de usuário;
 \item Interface baseada em web;
 \item Notificação por e-mail flexível de eventos predefinidos;
 \item Visualização em alto nível dos recursos monitorados a nível gerencial;
 \item Sistema de monitoramento centralizado. Todas as informações (configuração, dados de desempenho) são armazenado em banco de dados relacional.~\cite{doczabbix12}
	
\end{itemize}

\subsubsection{Zenoss core}

Muitas coisas em comum com o \textit{Zabbix}, além de poder configurar eventos e uma administração de erros, o \textit{Zenoss core} oferece:

\begin{itemize}
 \item Solução Software Livre GPLV2;
 \item Permite modelar o sistema de monitoramento de acordo com a infraestrutura;
 \item O sistema pode acessar cada dispositivo monitorado na infraestrutura e obter em detalhes informações sobre seus componentes e dependências;
 \item O \textit{Zenoss core} pode normalizar as informações obtidas para ficar em um padrão possível de comparar;
 \item Monitoramento sem agente;
 \item Configuração de herança para descrever como o dispositivo deve ser monitorado;
 \item Auto-descoberta e configuração de dispositivos;
 \item Monitoramento de desempenho e disponibilidade;
 \item Administração de falhas e eventos;
 \item Alertas e remediação;
 \item  Geração de relatórios.
\end{itemize}

Apesar da breve descrição, o \textit{Zenoss core} parece oferecer uma maior viabilidade para o nosso trabalho de obter relatórios que facilitem a rastreabilidade de erros. O \textit{Zabbix} ainda é uma opção, mas usaremos o \textit{Zenoss core} para melhor ilustrar o uso de uma ferramenta de monitoramento. A imagem abaixo ilustra a arquitetura do \textit{Zenoss core}:


\begin{figure}[H]
	\begin{center}
 		\includegraphics[width=1.0\textwidth]{imagens/arquitetura_zenoss.png}
 		\caption{Arquitetura do Zenoss~\cite{doczenoss12}.}
 		\label{fig:arquitetura_zenoss}
	\end{center}
\end{figure}

Existem muitas características comuns para monitorar e configurar nos módulos, entre elas:

\begin{enumerate}
 \item Extrair dados para monitoramento usando SSH, SNMP, ou WMI remotamente dos componentes;
 \item Usar comandos (\textit{zencommand}) para efetuar diversos tipos de operação, como verificar conteúdos de sites usando expressão regular, extrair dados;
 \item Monitorar fluxo de redes, disponibilidade de um ip ou porta que é usada para a transmissão de dados em modo geral, como por exemplo, a transferência de dados do RSO, comunicação entre componentes;
 \item Monitorar classes de serviços de rede, usando uma arvore para visualizar quais eventos são para monitorar, podemos monitorar e classificar a gravidade de falhas;
 \item Monitorar uso do armazenamento local, podendo indicar alertas quando o disco está cheio, e também criar triggers para remediar situações de risco;
 \item Monitorar o desempenho da CPU, podendo alterar a forma de visualização gráfica, criar triggers quando certos valores forem atingidos e alertar estados críticos;
 \item Monitorar processos(programas) usando seu PID(\textit{Process Identification}) e expressão regular(RegEx) para filtrar os eventos;
 \item Coletar logs de Windows(podendo ser de aplicações ou dispositivos). podemos usar a severidade dos eventos como filtro;
 \item Classificar eventos em Classe, Dispositivo, Componente, Estado e Gravidade.
\end{enumerate}

Para melhor ilustrar o uso do \textit{Zenoss core}, usamos o seguinte método de uso:


\begin{figure}[H]
	\begin{center}
 		\includegraphics[width=1.0\textwidth]{imagens/workflow_zenoss.png}
 		\caption{Workflow do Zenoss core~\cite{doczenoss12}.}
 		\label{fig:workflow_zenoss}
	\end{center}
\end{figure}

Como o foco do \textit{Zenoss core} é coleta de eventos, um evento deve conter valores sobre dispositivo, gravidade e campo de estado. Caso falte algum desses campos na descrição do evento, o \textit{Zenoss core} rejeita isso~\cite{doczenoss12}.

Os campos básicos de eventos são:
\begin{enumerate}
 \item Dispositivo;
 \item Endereço de IP;
 \item Estado do evento;
 \item Gravidade;
 \item Resumo;
 \item Mensagem;
 \item evid (ID único do evento).
\end{enumerate}

Sendo que cada campo de um evento é descrito com base em uma tabela de definição. Exemplos:

\begin {table}[H]
\caption {Campo do estado do evento}
\begin{center}
    \begin{tabular}{ | p{2,5cm} | p{2cm} | p{5cm} | p{5cm} |}
    \hline
    \textbf{Número} & \textbf{Nome} \\ \hline
    0 & Novo  \\ \hline
    1 & Conhecido  \\ \hline
    2 & Suspenso   \\ \hline
    3 & Fechado  \\ \hline
    4 & Resolvido  \\ \hline
    5 & Descartado  \\ \hline
    6 & Adiado \\ \hline
    \end{tabular}
\end{center}
\end{table}

\begin {table}[H]
\caption {Campo de Gravidade do evento}
\begin{center}
    \begin{tabular}{ | p{2,5cm} | p{2cm} | p{5cm} | p{5cm} |}
    \hline
    \textbf{Número} & \textbf{Nome} \\ \hline
    0 & Feito  \\ \hline
    1 & \textit{Debug}  \\ \hline
    2 & Informação  \\ \hline
    3 & Aviso  \\ \hline
    4 & Erro  \\ \hline
    5 & Critico \\ \hline
    \end{tabular}
\end{center}
\end{table}


Usando o módulo de visualização e gerenciamento de eventos do \textit{Zenoss core}, o \textit{Master Event Console}(Painel de ferramentas na Figura  ~\ref{fig:master_event_console}), podemos fazer consultas e selecionar apenas eventos interessantes para coletar.

\begin{figure}[H]
	\begin{center}
 		\includegraphics[width=1.0\textwidth]{imagens/master_event_console.png}
 		\caption{Painel de ferramentas gráfica do \textit{Master Event Console}~\cite{doczenoss12}.}
 		\label{fig:master_event_console}
	\end{center}
\end{figure}

Temos as seguintes funcionalidade do \textit{Master Event Console}~\cite{doczenoss12}:
\begin{itemize}
 \item Personalizar dados (colunas);
 \item Selecionar, ordenar e filtrar eventos;
 \item Trabalhar com pesquisa em tempo real;
 \item Salvar ou atualizar a visualização;
 \item Visualizar detalhes do evento;
 \item Conhecer eventos;
 \item Retornar eventos para um estado novo;
 \item Classificar eventos;
 \item Fechar eventos ativos ou marcar como estado ativo;
 \item Exportar os dados de evento;
 \item Criar eventos.
\end{itemize}

Com essa funcionalidade, é possível coletar eventos no padrão para minerar o banco de dados NoSQL.

\subsection{Estratégia potencial}

Usando o \textit{Zenoss core} em um servidor, o sistema mapeia toda a rede, onde podemos configurar o que vamos monitorar em cada componente.
Considerando o modelo conceitual do Observatório Web como descrito nesse documento, a aplicação de uma das ferramenta de monitoramento varia em cada componente, segue uma possível aplicação do ponto de vista operacional em cada componente correspondente:

\subsubsection{Banco de dados MongoDB:}
\begin{itemize}
 \item Monitorar o uso de rede em relação ao tempo e disponibilidade;
 \item Monitorar o uso de CPU, Memória e Disco Rígido;
 \item Monitorar o processo do coletor de dados;
 \item Monitorar a disponibilidade do site Twitter.
\end{itemize}

\subsubsection{Componente de extração:}
\begin{itemize}
 \item Monitorar o uso de rede em relação ao tempo e disponibilidade;
 \item Monitorar o uso de CPU, Memória e Disco Rígido;
 \item Monitorar processos das entidades responsáveis pela filtragem.
\end{itemize}

\subsubsection{RabbitMQ:}
\begin{itemize}
 \item Monitorar o PID do aplicativo;
 \item Monitorar o uso de CPU, Memória e Disco Rígido.
\end{itemize}

\subsubsection{Mysql:}
\begin{itemize}
 \item Monitorar o uso de CPU, Memória e Disco Rígido;
 \item Monitorar o uso de rede em relação ao tempo e disponibilidade;
 \item Criar Triggers em momentos onde o sistema atinge estados críticos.
\end{itemize}

\subsubsection{Outros Componentes:}

Em cada componente mais simples, podemos monitorar atividades que geram falhas comuns como o uso de CPU, memória e disco rígido.

\section{Visão funcional}

A visão funcional tem como objetivo descrever a transformação dos dados de uma parte do sistema do Observatório da Web, monitorado pelo Zenoss e assim gerando logs que serão explorados e utilizados para o rastreamento das falhas que ocorrerem durante os processos de coleta massiva de dados, extração e filtração.

\subsection{Estratégia potencial}
Para o monitoramento do sistema do Observatório da Web, será utilizado o programa \textit{Zenoss core} que irá gerar logs de falhas e os enviará a um banco de dados. Estes logs serão processados por um algoritmo, sendo criados eventos que serão armazenados em um banco de dados NoSQL. A partir destes eventos, poderá ser possível uma filtragem e busca a partir da interface de uma ferramenta de inspeção. Esta ferramenta filtra, de forma sistemática, a medida que vamos inserindo as palavras desejadas, como “erro” ou “nome da máquina”.
\begin{itemize}
 \item Fonte de dados - Componente externo: RSO;
 \item Coleta massiva de dados - Ferramenta que coleta os dados de maneira atualizada;
 \item Filtragem - normaliza os dados coletados, e os prepara para aos algoritmos de extração;
 \item Extração - fazem as operações necessárias para que as técnicas computacionais possam trabalhar;
 \item Zenoss core - monitor de componentes e suas comunicações;
 \item Log de dados - base de dados que armazena os logs gerados pela ferramenta Zenoss;
 \item Criar eventos - algoritmo que criará eventos e armazenará no NoSQL;
 \item NoSQL - base de dados que armazena os eventos criados;
 \item Busca e filtração das informações - algoritmo que rastreia e filtra as informações que o agente externo busca;
 \item Visualizar falhas - interface utilizada pelo usuário para fornecer os dados desejados para o rastreamento das falhas.
 \end{itemize}

\begin{figure}[H]
	\begin{center}
 		\includegraphics[width=1.0\textwidth]{imagens/proposta_sistema_rastreamento_falhas.png}
 		\caption{Proposta para sistema de rastreamento de falhas.}
 		\label{fig:proposta_sistema_rastreamento_falhas}
	\end{center}
\end{figure}

\subsection{Ferramentas}

Para a coleta das falhas relacionadas ao Observatório da Web, utilizaremos o Zenoss core para o monitoramento do hardware e rede. A partir dessa base de dados, faremos a composição do evento a partir do proposto por Araújo et al~\cite{araujo10}, um evento contendo várias tags e uma tag podendo pertencer a eventos diferentes entre si, sendo que uma tag é representada por um par nome-valor, representando as propriedades contextuais do sistema no instante em que o evento foi criado. Este evento será armazenado em um banco de dados que suporta o formato proposto, descrito em Araújo et al~\cite{araujo10}.

\subsection{Falhas funcionais}
Depois de analisado o Observatório da Web, foram levantadas possíveis falhas funcionais que podem vir a ocorrer ou existir em seu sistema. As falhas funcionais enumeradas de acordo com o observado e extraído de Avizienis et al~\cite{avizienis04} que poderiam influenciar no correto funcionamento do sistema seriam:

\begin{itemize}
 \item Falhas de desenvolvimento;
 \item Falhas de interação.
\end{itemize}

 Dentro das falhas de desenvolvimento e de interação, é observado uma hierarquia de falhas que objetiva a análise destas no contexto do sistema. Quanto as \textbf{falhas de desenvolvimento:}

 \begin{itemize}
 \item Falhas de desenvolvimento;
 \item Falhas internas;
 \item Falhas cometidas por humanos;
 \item Falhas de software;
 \item Ou falhas não maliciosas ou falhas maliciosas;
 \item Ou falhas deliberadas ou falhas não deliberadas;
 \item Ou falhas acidentais ou falhas por incompetência;
 \item Falhas permanentes.
\end{itemize}

Quanto as \textbf{falhas de interação:}

\begin{itemize}
 \item Falhas operacionais;
 \item Falhas externas;
 \item Ou falhas naturais ou falhas humanas;
 \item Ou falhas de hardware ou falhas de software;
 \item Ou falhas não maliciosas ou falhas maliciosas;
 \item Ou falhas deliberadas ou falhas não deliberadas;
 \item Ou falhas acidentais ou falhas por incompetência;
 \item Ou falhas permanentes ou falhas transientes.
\end{itemize}

Dentro deste conjunto de falhas, podemos identificar algumas defeitos que podem vir a ocorrer dentro do Observatório da Web:

\begin{itemize}
 \item Coleta de dados
 \begin{itemize}
 \item Erro ao solicitar \textit{stream}
 \begin{itemize}
  \item Falha interna
  \item Domínio da falha: Conteúdo e tempo – falha de parada
  \item Detectabilidade: Detectável
  \item Consistência: Consistente
  \item Consequência: Grave
  \end{itemize}
 \end{itemize}
 \item Banco de dados
 \begin{itemize}
  \item Armazenamento incorreto dos dados coletados
  \begin{itemize}
   \item Falha interna
   \item Domínio da falha: Conteúdo de tempo – falha silenciosa
   \item Detectabilidade: Indetectável
   \item Consistência: Inconsistente
   \item Consequência: Média
  \end{itemize}
 \end{itemize}
 \item Filtragem
 \begin{itemize}
  \item Problemas no algoritmo
  \begin{itemize}
   \item Falha interna
   \item Domínio da falha: Conteúdo
   \item Detectabilidade: Indetectável
   \item Consistência: Consistente
   \item Consequência: Grave
  \end{itemize}
 \end{itemize}
 \item Extração
 \begin{itemize}
  \item Problemas no algoritmo
  \begin{itemize}
   \item Falha interna
	\item Domínio da falha: Conteúdo
	\item Detectabilidade: Indetectável
	\item Consistência: Inconsistente
	\item Consequência: Grave
  \end{itemize}
 \end{itemize}
\end{itemize}

É possível observar que a falha descrita para o coletor de dados pode ser ocasionada por uma falta de desenvolvimento, interna, por humanos, de software, e permanente, assim como para o banco de dados, a filtragem, e a extração. Os outros tipos de falhas de desenvolvimento que podem ter ocorrido não são possíveis de identificar.

Quanto as falhas de interação, poderíamos avaliar a partir da ferramenta de inspeção proposta por Araújo et al~\cite{araujo10}, pois a mesma terá como objetivo inicial filtrar os logs produzidos nas etapas citadas anteriormente: coleta de dados, filtragem e extração.

\begin{itemize}
 \item Inserir palavras erradas na busca da falhas
 \begin{itemize}
  \item Falha externa
  \item Domínio da falha: Conteúdo
  \item Detectabilidade: Detectável
  \item Consistência: Consistente
  \item Consequência: Média
 \end{itemize}
 \item Identificar uma falsa falha
 \begin{itemize}
  \item Falha externa
  \item Domínio da falha: Conteúdo
  \item Detectabilidade: Detectável
  \item Consistência: Inconsistente
  \item Consequência: Grave
 \end{itemize}
\end{itemize}

É possível observar que as defeitos descritas pode ser ocasionada por uma falta operacional, externa, por humanos, e de software. Os outros tipos de falhas de desenvolvimento que podem ter ocorrido não são possíveis de identificar, salvo o fato de “inserir palavras erradas na busca da falha” que é uma falta transiente e “identificar uma falsa falha” poder ser ou permanente (caso modifique corrija a falsa falha) ou transiente (caso não modifique a falsa falha).


